NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/13642

Internet Message Format | 1996-08-05 | 5.1 KB

Path: dildog.lgc.com!not-for-mail
From: [e-mail] (Mike.Rovak)
Newsgroups: comp.lang.c++
Subject: Re: C++ vs Delphi 2.0
Followup-To: comp.lang.c++
Date: 26 Mar 1996 12:44:14 -0600
Organization: tulsa.lgc.com
Sender: Mike Rovak
Message-ID: <4j9dtu$[e-mail]>
References: <[e-mail]> <4ims71$[e-mail]> <[e-mail]> <4j2u9o$[e-mail]>
NNTP-Posting-Host: aris.tulsa.lgc.com
Summary: ymmv
Keywords: language comparison

In article <4j2u9o$[e-mail]>,
Thaddeus L. Olczyk <[e-mail]> wrote:
>[e-mail] (Richard Mazzaferri) wrote:
>
>>> The problem with Delphi is that most people don't seem to realise that
>>> true programming power\flexibility and ease of use are generally
>>> mutually exclusive. Delphi is in Pascal ... which is fundamentally a
>>> teaching language and was never meant as anything more. C++ .exe's
>>> tend to be smaller and faster than Delphi .exe's. Although C++ has no
>>> real standard, it's getting there and it is younger than Pascal.
>>> Pascal tries to be English-like and this it has become pretty rigid.
>>> (This is a personal opinion) to fit smoothly ith OOP. Additionally, if
>>> you use Delphi, you'll find that the general feel of it discourages
>>> one from using code, and directly controlling things. This can't be
>>> good!
>>
>I have argued in the past and continue to argue now that it is a misnomer
>to call Delphi OO. It partial emulates the C++/Eiffel model of static
>typing, but misses severely by what it keeps out. It partially emulates
>the Smalltalk model of dynamic typing, but in a convoluted way.

Having used both Delphi and C++, I might could shed some light on the
subject.

I find both Delphi and C++ flexible and easy to use when a project is
properly engineered to optimize the use of the preferred tool. If you want
a simple database application with little frill, there is no question
that Delphi will allow you to produce the finished app in a matter of
days. Even in your spare time. IMHO, if you make a living doing this
kind of work, then any theoretical or mathematical argument about
OO this or OO that, and Smalltalk this or Eiffel that is basically
a non-issue.

My personal opinion is that the small differences in syntax between C++
and Pascal alluded to above are insignificant ( { instead of begin, and
so forth).

I find that the extended syntax of Delphi, where all class instances
and handled as references implicitly, is a productivity boost and a
great simplification, which helps to prevent pointer access bugs.

>>The biggest omissions are multiple inheritance (which can generally be
>>faked with a bit of work) and templates (no workaround :-(.  Some of the
>
>Many times a lot of work or virtually impossible.

Nothing is impossible if a genuine need exists (Mike's Law).  :-)
That's where creativity and engineering skills come in.

>>and the first couple of days with Delphi felt quite strange, because I
>>didn't have the broad knowledge of the entire system that I had with
>>various C++ compilers.  After that, it was *very* pleasant and *very*
>>productive.  The EXEs tend to suffer from the first couple of hundred of kB
>>of run time library (which is not a big worry in most cases these days),
>>but they are not particularly slow in my experience.
>>
>>Each to his own :-)
>>
>>Have fun,
>>    Mazz.
>>[e-mail]

Once you get past the 100k for the front end, the code for actual forms
takes up very little space, perhaps a few k per form. The database code
also adds a few hundred k as well. The more high-level your front end,
the more you can expect a few hundred k for the overhead to support it.

The major engineering problems with Delphi are, IMHO, as follows, and
in my mind keep Delphi from being used much more widely in commercial
applications:

1- As is, Delphi does not support modeless forms from Delphi DLL's.
   I don't know if this is fixed in 2.0, or if someone has come up
   with a workaround. Surprise!

   Not a problem with MFC.

2- The Borland Database Engine is not engineered to be used by multiple
   tasks simultaneously from a DLL. This is discussed in Pacheco &
   Texeira's book. Don't know if someone has come up with a legitimate
   workaround (as opposed to the single-user-at-a-time hack mentioned
   in the book). Surprise!

   Not a problem with MFC. ODBC uses whatever pointer to an ODBC
   environment you supply.

3- VCL not engineered to be used from a DLL and linked with dynamically.
   IMHO for a large, complex commercial project where frequent upgrades
   occur, this is a MUST.

   Not a problem with MFC.


If you don't care about the above issues, and need to get your product
out the door, then Delphi will beat everything else out there, hands
down.


-- Mike

------------------------------------------------------------------------
Disclaimer: My opinions do not necessarily reflect those of my employer.
========================================================================
------------------------------------------------------------------------
     [e-mail]

========================================================================